Agile Otter Blog

This week I wrote a useful utility and taught some Python to a peer, attended a really great work session and a rough estimating session. I did some WIP management activities with my team, I broke the application, I worked with some awesome partners, went on a bit of a refactoring binge, devised (with partner) a grand strategy, and got stuck on tiny little problems I couldn't see over. This has been an awesome week. We have been doing some big refactorings, moving big and critical chunks from one module to another, and dealing with the fallout. I don't know how to tell you how important the tests in our code base have been. I would have spent all day lost without them. We would move a component, build, resolve build troubles, rinse and repeat. Finally, at end of day, I got all unit tests and fitnesse tests turning green, EXCEPT for a few that won't test because they do horrible things and need remediation. When our tests failed, it was not because the tests were bad (exc...

To make software, you need people who are skilled, creative, quick-learning, thoughtful, and engaged. You might be able to skimp on 'skilled' if the rest of your team provides a social learning system (via pair programming, test-driven development, book and link sharing, impromptu teaching, design talks, etc). You cannot really skimp on the characteristics of being creative, thoughtful, and engaged. If you tell someone that you don't care how they feel, they will work in an unfeeling way. If you tell them that you don't care what they think, they will work unthinkingly. If you tell them not to participate, they will disengage. This (IMHO) is why use of corporate software is so often without soul and without joy. If one self-important side tells the other to shut up, or to stop asking questions, or to leave the decision-making process, then he has switched off an important piece of capital equipment. If you treat a knowledge worker as a drudge, she will turn off h...

A friend of mine (Hi George D) suggested that this would make a good poster, but all I have is a couple of blogs, so here is the message that inspired my buddy. My experience is that the less well a team has done in the past, the more oversight is piled on, and that oversight reaches higher and higher levels. There really is no legitimate reason for the CEO to want to know which programmer 5 or more levels below was assigned to a particular task and if he's behind schedule by a week or so. In healthier organizations, the groups and managers that interface with the development group tend not to have the same meddlesome urges. In our transitions, the biggest problem we face tends to be peeling back the expensive and unnecessary oversight. If the team can be rebooted and work with a single stream of smaller, simpler stories (rest of agile practices included) then they can win over the rest of the org in relatively short order. Sometimes in only a year or two, som...

If your code doesn't really work, then it doesn't matter how quickly you wrote it. Abandoning quality in pursuit of speed is a fool's errand. It has been discussed plenty of times in about any management book you want to look at, and especially by the brilliant minds like Deming. If you write your code badly, you can release it without awareness of bugs, and that takes it off of your plate. You may be rewarded or recognized for your quick work. It feels good today. Your team is recognized for being heroes within the company because you are smart, and get things done. But tomorrow a customer tries to use it and it fails. The customer is no longer happy that the feature was delivered, because it's junk. In fact, as far as the customer is concerned the whole product is now junk, your company is junk, and the developers are pure rubbish. Loss of good will. Think how you feel when you get the Fail Whale, and you are a friendly customer and unusually forgiving. How d...

After arguing for decades that it is not so, I find out that I'm wrong. This is from a 2007 article on construction. 1. If it takes six months to build a house, then 85 percent of the time is spent on two activities: waiting on the next trade to show up and fixing mistakes. 2. Clemson's Professor Roger Liska conducted an analysis of productivity on the construction industry and found that the average construction worker operates at only 40 percent efficiency. 3. Critical shortages exist in qualified, skilled workers and labor issue futurist Roger Herman predicts the situation is only going to get worse. 4. Business Week's 2007 Investment Outlook Report indicates the return on equity (ROE) for all U.S. industries is 17.9 percent, while the ROE for the construction industry is a mere 9.7 percent, despite the recent construction boom. 5. Industry customers are frustrated with poor quality, confrontation, excessive change orders in quantity and dollar value, schedulin...

Presented in the most pleasant way possible, by Daniel Pink & friends: The whole "purpose maximizers" thing gives me hope in ways that "enlightened self interest" never, ever has.