You figure with a collocated team information will flow freely. It does to some extent, but things can still get missed. On many Sprints one of the key safety mechanisms are the daily standups.

A typical hypothetical example might be a developer reporting an impediment about how they had spent half the day trying to implement a PDF report. The developer had been working solo, just heads down at the keyboard. Within seconds of mentioning this at the standup, a tester would point out he thought the report was just going to be a web page and soon an analyst might bring up an old discussion were the business decided they just wanted an online screen for the report, they really didn’t need to print it, and especially not as a PDF. Impediment solved.

The lesson here is:

• A good standup where people quickly describe their commitments, what they worked on and impediments can catch problems early. This is very much in the line of the lean idea of ‘stopping the line’.
• If your standups consist of team members stating, well I finished #37 and I’ll be working on #102 today you’re missing critical information.

• Many practices reinforce the idea of capturing issues or opportunities early and often.

• Automated unit tests to capture issues as they’re being coded.
• Continuous builds to catch integration problems.
• Collocated teams so that people overhear important conversations or get consulted on decisions because they’re right there when something comes up.
• Daily standups to allow for at least a daily sync up.
• Sprint reviews to bring stakeholders in to see what’s being delivered.

Instead of having wrong assumptions slip through they can be corrected within 8 hours. And that’s less hours of wasted work. Not a bad investment for a 15 minute meeting.

I’ve yet to develop carpal tunnel injuries as a developer. I spend much of the day standing, walking around, talking to staff, and going to meetings. Not much time to spend hours on end at the keyboard without breaks.

One of my brothers who likes to experiment with different keyboards brought over his vertical keyboard this weekend to show us how it worked. He’s so impressed with it he’s bought one for home and one for work.

I only spent about 15 minutes with it, but I found it easy to use. Apparently touch typing works just as well with your hands tilted at 90 degrees. I was probably a few words per minute slower, but I assume that goes away with a little practice. The one change that clobbered me a few times was on the left the space bar produces spaces, but on the right side it’s a large backspace key. Anyway if you have carpal tunnel issues it might be worth taking a look at.

Tobias Mayer has a great post on modifications to the standard Scrum that have worked for him. One of these is the idea that tasks are not measured in hours:

Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such. This approach serves two purposes: firstly, ease and accuracy of burndown (burndown on tasks rather than hours, making the whole process binary: a task is done or it is not done) and secondly it raises impediments which developers themselves may not see. For example, an incomplete task may be in that state because a developer was called off into some long and meaningless meeting, but because “that is the way we work around here” this is not seen as an impediment. Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

Nice to know I’m not alone on this idea of trying to get away from a focus on the exact hours for a task. If all of the tasks are a day or less, tracking becomes simply done or not done. We haven’t used this approach formally on any Scrum projects, but I may bring it up at a retrospective and suggest to a team that they might try it out for a Sprint. I also really like the idea of having a burndown chart that tracks number of tasks completed rather than hours.

The whole point is are you getting the backlog items, aka features, done or not. The tasks are just some of the details on how you get there.

Yes, Scrum does have a secret handshake, you can find out about it if you take one of the CSM courses. It’s a little bit of fun nothing all that serious. It also involves ‘woofing’ like a sheepdog. Apparently it’s ruffled the feathers of some ‘serious’ Agile practitioners, to the tune of 30+ messages on the Scrum Yahoo group. After seeing some of the debate Ken posted his thoughts:

You know, I think I’m really glad that I added something light such as a secret, encrypted handshake. It really seems to be a good way of weeding out people who don’t have a sense of humor and are, maybe, too serious about everything. Or, maybe, I expect too much from CSM’s. I think that the work we are undertaking is so serious and so hard that any way that we can inject levity is well worth the effort. I always thought that “woof” created some sense of camaraderie, but maybe I’m wrong.

If you’re not having fun at work, at least some of the time, it’s time to find a new job. It’s an ‘Agile’ lightweight process not a high ceremony, formal, always serious process.

CIO Magazine has a great article on Users Who Know Too Much (And the CIOS Who Fear Them). The tone of the article suggests that IT organizations need to embrace new web based technologies from IM and GMail to BaseCamp and WordPress. They’re making your business a better more productive place even if your sysadmins are screaming about those ‘idiotic users.’

Rob Israel, CIO of John C. Lincoln Health Network, has seized on this and come up with a novel solution:

“I’m the only person in IT allowed to say no,” he says. Conversely, his IT employees have only three options: approve a request, research it or pass it up to him. According to Gold and Israel getting a reputation for saying yes will encourage users to come to you with ideas. That gives you the chance to learn what it is that the user is really trying to do and come up with a way to do it that won’t compromise security.

Assume that your internal customers are using a new tool for a good reason and support their attempts to improve productivity. Rob sounds like the sort of progressive CIO we need to see more of.