Agile Otter Blog

How it Happens You realize that you're not getting as much done as you expected to get done. It's troublesome because you have plans and promises and releases to deal with. You're likely to end up the scapegoat when your behind-ness snowballs into a large organization-wide issue. You also have quality problems. Your team leads estimate that the teams are spending 70% of their effort on defect-fixing activities.  It dawns on you that you can get back 70% of the productivity of your team if you can spin up a separate team to handle bugs! Now one team can be 100% dedicated to adding new functionality without being encumbered by bug-fixing work.  After months, you find that the defect density has not improved from your effort. You see a ramp-up in the number of defects fixed per month as the bug team's diagnostic and corrective skills improve, but they are still lucky to hold even against the tide of defect injection. Why doesn't this work? What has g...

The basics are well-known: Everyone knows the basic cycle of TDD. You should also know the improved Industrial Logic version of the TDD cycle . You have heard Uncle Bob's three rules . But there is so much more to know. I have been gathering little sound bites for you which may help you build your skills and knowledge. Please feel free to drop additional factoids or questions. I'm happy to explain any of these at length if you like. Here is my list: Your code has two parts: the part you have covered with TDD, and the part that requires you to use a debugger. Microtests are F.I.R.S.T.   (you cannot TDD after writing the code) Only microtests are appropriate for TDD; other tests are useful, but not for TDD. Microtests are not all your tests - you need other levels of test still.  TDD does not validate your system; it only speeds development and improves quality. TDD without a pair programming partner is like programming while wearing only one shoe. ...

A few ideas rattling around my head need a place to live while I think them through, so I am shoveling them into the ole blog so I can think about prepping materials and exercises for a class I am teaching soon. I was considering an archetype developer that we've all seen (heck, half of us have been ) and how hard it is to reach this particular type when doing any kind of a technology or methodology change.  Here's the stream: There is this guy who believes he's an exceptional programmer, but underrated and under-respected by his peers. Why does he think he's good? Maybe he doesn't really believe it. maybe he's afraid. (@RonJeffries) A guy who never thinks or reads about programming off-hours, never goes to talks, hates pairing, skips reviews. Thinks himself an expert? b/c folks like that have a Darwinistic career advantage over peers who /are/ good but think they're mediocre/overpaid/overrated (@LancePurple). I suspect Dunning-Kruger Effect . Not go...

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

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on: There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases. Rockstars If you are the rock s...

Our office firewall gets in the way of Yuuguu , probably by blocking UDP traffic I'm not sure what the real . Finally a coworker was WFH and we were able to try it. Hey, it worked. Lag wasn't bad, control wasn't hard to trade, and it didn't really get in the way. It really shared the other guy's screen, not just certain windows. That was very convenient, but it also meant that I could see his IM and email notifications and the like. If you worry about such things, be warned. OTOH, it means that he could pop up editors, SQL tools, log tail programs, and the like without having to explicitely share them with me as he as to do in webex. Yuuguu didn't include voice, but included a voice conference line. It does nice instant messaging and screen sharing, though. We skyped for voice, and yuuguu-ed for screen share. It can tie into your instant messaging accounts, which makes it easier to find people you know. We had work to do, so we didn't spend so much...