I’ve worked in several IT shops where various CIOs sold the business on how some great new Enterprise technology was going to make IT better, faster, and more successful. I’ve never seen it work out all that well.

In one particularly absurd environment they went through at least three completely different Enterprise technologies in the space of about five years.

• First there was Rapid Application development with Powerbuilder.
• Next up was Java and J2EE.
• Then it was .NET that was going to save the day.

The end result was predictable. The large centralized IT department could barely deliver an application because they were always on a learning curve. The business picked up on this. Multiple CIOs and middle managers were demoted or asked to be successful elsewhere. The central IT department was largely broken up and distributed out to individual business units. There is very little reuse since each unit does it’s own thing, but at least they feel like they have some control.

David Anderson recently posted about his reading of Richard Farson’s Management of the Absurd.

Farson contends that in flat structures with self-organizing teams the team member will weed out the the stronger member. In hierarchical structures people will do the Darwinian approach and weed out the weaker members.

As David Anderson notes this is obviously a problem in an Agile context. I’ve always followed the opposite approach. My two rules are:

• At least two developers per project. One developer is just too risky and doesn’t share knowledge.
• If possible at least one tech lead per project who’s top responsibility is to bring up the rest of the team. As developers grow in experience this is becoming easier to cover.

I haven’t seen developers go after the stronger team members on our Scrum projects. I’ve actually seen more of the Darwinian behavior. What I’m really looking forward too is I’m able to staff whole project teams soon with strong experienced developers. I just need to convince senior management not to swap out 80% of the technologies everyone’s mastered again and start much of the learning process over.

As an old fan of Survivor I can see that given the context of a million dollar prize cooperation tends to lead to voting off the stronger members first where possible, because they’re real threats. I just don’t think that’s how Agile projects usually work.

Considering contrarian ideas helps expand your vision, so it might be worth picking up the book. Some crazy ideas really work better than expected.

Typically daily Scrums are held as early in the morning as reasonable or later in the afternoon. Due to some strange circumstances the intranet portal project I’m Scrum Master on has a daily Scrum at 11:15, right before lunch. At our retrospective early this week I asked if we should move it to another time or at least to say 11:00. The universal response was no, don’t move it.

The reasoning across the team was that by having it right before lunch it forced the meeting to fit into the 15 minute window and it cut down on the number of followup meetings held just after the Scrum. They liked having that added pressure to get the meeting done before running off to lunch. Strange, but it’s up the team to self-organize.

I remember searching hard for good technical podcasts about a year ago. There were really just a few at that point like Drunk and Retired, ZDot, and the Polymorphic Podcast. Today there’s a wealth of them. Just following a blog link I noticed NetObjectives has a Lean Agile Straight Talk podcast.

All this means is I have about 48 hours of backlog right on the old iPod and I can afford to be picky. A lot of podcasts I would have listened to on IT Conversations now don’t even warrant a download.

About 9 months ago I tried to explain to one of my developers the idea of an iteration zero. Sort of a quick organization of setting up for the project for a few weeks. I tried to find some references to it to point him too, but I didn’t manage to find any even though I was convinced I read about it somewhere.

If Scott Ambler is right it’s an assumed idea for Agilists, but “little has been written about this subject.” His definition is:

Agilists refer to the initial iteration of a project as “Cycle 0,” during which you determine whether the project is feasible, setup the technical environment, start building the team, and do sufficient modeling to support these activities. Sounds like what you do on a traditional project? Absolutely. The difference, however, is agilists achieve the same goals with a lot less effort—Cycle 0 is typically a week or two at most.

Small anecdotal evidence, but out of our three official Agile pilots the one that went the smoothest had a good 3-4 weeks in Cycle 0. The other two leaped off on Sprint #1 with minimal planning. The biggest pain seemed to be that very little initial work had gone into requirements, use cases in our world. For Sprint #1 it was hard for the developers and QA folks to do estimates and it’s taken a while to catch up.