Agile Otter Blog

I developed an quirky technique for dealing with the intermediate states of a refactoring. I call it the "poop" method (no biological metaphor implied). This method is far less controversial than one might suspect, but it is mildly unsettling. I find myself working in a legacy code base. Refactoring requires me to take several small steps, each of which leaves a sub-optimal intermediate state. I decide to mark the code with some kind of comment that will indicate that the work there is incomplete. It needs to be a word that doesn't normally appear in code, and which is clearly and obviously undesirable. If I put TODO, it will either get lost in the other TODOs left by well-intentioned people, or else will be stopped by a lint tool that takes such things seriously. Most obscenities would also be a little too likely to be duplicated by someone having a bad day. My marker comment should not be something so obscene that it will offend or embarrass myself or my reviewers...

This was a wonderful, long, crazy day. I woke up with a meditation on my mind. I was feeling calm, happy, centered. Morning routine was a breeze, and the walking route to the conference hotel is much more comfortable than the old one. I spent a lot of time in coaches' corner again. I met some really nice people and had some great talks. I learned the "S.C.A.R.F." acronym and how to use it. I saw old friends. I met new friends. The Grand American hotel is a wonderful conference hotel. It is comfortable, attractive, and divides into smaller areas nicely. The staff are ninjas, keeping the place clean and preparing for all the events and reconfigurations quickly and quietly. In fact, if you turn your back on your soda, it may totally disappear. James Grenning gave me a glass emblazoned with his book cover, and I had to guard it carefully lest it be swept away by cleaning ninjas. They are so quiet, polite, and efficient that one can never be annoyed with them. They are ...

I was telling Esther Derby about a little trick I worked out some time ago at one of my clients. The retrospectives had gone stale, with team members offering the same "we should..." list iteration after iteration.  I suspected that they didn't feel that they really had the authority or permission to change their process for the better. I had a good relationship with the CIO and wandered into his office. I said, "we have some changes we want to make, and they won't really cost any money or affect other departments, and I just wondered if you think it would be okay to do them."  The CIO looked at me incredulously, "Of course. That's a silly question to ask." "Alright, then there is this other change.  It might take a few man days out of each iteration, but it will be helpful for the team.  Would that be okay?"  He sighed, "If it's a few man days per iteration, we can afford that. Go ahead and take that time. You don'...

I just can't get it in my head this was Wednesday.  I'm very tired.  I'm an introvert, you know, and we draw energy from alone time or time with a small number of close friends.  Being in rooms with hundreds of people most of the time is really work.  On the other hand, I get energy from my work, and spent a lot of time talking about work. I spent the morning with Michelle from NavTeq, talking about people, processes, transitions, and strategies for making other people more successful. I'd re-met a fellow from NavTeq after my talk on pairing yesterday, so it's cool that I'm seeing so many of my Chicago cousins. I'm hoping to see more of them in the future. I attended a tool demo later, but I didn't realize it was a testing tool for C#. I thought it was going to be a talk on how to bring testers and coders closer together and blur the lines between them. I left disappointed, but on the way out met a nice fellow who is a new scrum master. We chatted un...

Overall, pair programming isn't as controversial as you've heard. It depends on your styles of pairing. Some styles of pairing are very common, even among non-agile teams. They tend to be episodic, and last just long enough to get or give some aid. The good news is that they work. If a team views pairing with trepidation, these are common, non-threatening forms to start with: Rescue Pairing Training Pairing Brainstorming Experimenter/Researcher Others are such bad ideas that they are rightfully avoided by all sane teams I've seen so far.  If you are considering pairing, and a team member balks, you should see if their mental model of pairing matches one of these styles. I suspect a team should decide that these styles will never be practiced personally, or tolerated within the team's pod.  You have my blessings to object to pairing if "pairing" means: Worker/Rester Worker/Watcher Master/Slave Bully/Victim Writer/Critic Ball-and-chain pair marriag...

A lot of today was spent in the Coaches' Corner, where several more convention-goers were served with expert advice. I spent a chunk of my "alone time" today working on my "Agile Fundamental Apologetic" talk for Thursday (Fringe stage).  I hope to establish that if we weren't doing agile, we would have to do something very like it. I even got to pair on some of the slides, which was a great time. Jeff was finalizing his Test Abstraction talk (based on our Agile In A Flash card), in which he showed some poorly-composed Fitnesse tests, and some much more well-composed, abstract versions of the same test. It was practical and useful. I think he opened testers' eyes to new possibilities, and that 7 minutes talk will have reverberations in many places. After Jeff's talk was my own. Mine was titled "Will Pair Programming Ruin My Company?" in which I answered a few questions I've heard from managers over the years. Given how much controv...

This has been a very good day.  I was able to staff the Coaches' Corner and visit with other coaches when we weren't engaged with convention-goers.  I enjoy the interaction, though I'm admittedly an introvert. Jeff Langr is here, and we were able to talk about many things and even promote the Agile In A Flash deck.  Three copies went to the live aid silent auction. I was looking dapper in my blue Industrial Logic shirt and sharing the Agile love and coaching philosophy with people who were interested. We talked about measurement, e-learning, and raising self-coaching teams. We talked about business and busyness and listened to many stories.  I was also given a Lean Dog fuzzy hat, which I sometimes wore when I wasn't feeling to warm or was unconcerned about creating mental ambiguity about my situation. This place is a who's who of object mentor alumni. All my old friends have new gigs and new ideas and it's wonderful to see them all. The ice breaker is ov...

I'm doing some reading and some experiencing, keeping my eyes open for the concept of leadership. One can see leadership as a combination of visibility and confidence. This seems to work out pretty well, as an observation in arrears. Leaders who are successful often have high visibility and make decisions with a high confidence that things will work out well. When leadership works, I see it as the leader understanding the team and promoting the team by  improving the teams alignment with the hierarchy of the company and its customers, making use of the team's strengths, and helping . Such a path seems to grow confidence, and the success gives visibility to the team and its leaders. This is the slow, steady path. I see some leaders succeed by other means, some seeming rather virtuous and others less so. I'm particularly critical of those who see leadership as wresting authority from others though political games and social manipulation. Such leaders may actually inspir...