For me it started with Battlestar Galactica. I was excited that the new season was starting and the writers were going to wrap up the storyline. The week before the show started, The Sci-Fi channel ran some BSG "preliminary" shows -- I guess to get people excited about the new season.

One of the shows was basically "What happened up to now." It went over all of the plot points. That made sense.

The second show was a differenct can of worms.

As we all know, agile is not a very checklist-friendly methodology. In fact, it's probably a fair thing to say that Agile was created in response to overly-heavy, checklist-intensive methodologies.

So why in heck would you want a checklist for Agile teams?

I guess most people would think being wrong is a bad thing, but I look at the ability to be wrong to be a key indicator of a healthy team.

Hidden Agendas are fun. They're great. Everybody should have a hidden agenda --- NOT!!

On the other hand, isn't the point of agile all about putting the process of team discovery and organization above the individual? Aren't we all tired of the days where cloistered groups of experts created perfect requirements, test, and other docs and then handed them off to one another? Less smart people can accomplish more in an agile environment because the team is always adapting the product to the needs of the business owner. Agile processes are always providing feedback, enabling organic growth. Agile teams beat smart teams with too much structure easily, right? Experts and rigid expert ways of doing things are most times too rigid for optimal success, right?

This is an argument that has a long pedigree. It touches philosophy and politics, and -- you know me -- let's take a look at part of the discussion.

It started out simply enough: I was sitting in O'Hare a month ago waiting on a flight that was delayed. Across the aisle from me a young soldier was on his way home.

It's good to know whether you are
designing the nuclear power plant or driving the technicians to the site

I have kind of a weird job. While I help large organizations run their software teams a lot faster, I'm also not much of a self-promoter. I don't have any books I've written (although I've authored quite a bit of other stuff), I don't do seminars or conferences. And when I say "I don't do conferences", I mean I don't do them at all. I've never found much use for them and I don't see much reason to start now. Instead I like reading a lot of authors and comparing notes. To me, it gives me a much better feel for where the industry is and where I'd like to help out.

But I'm right on the cusp. For instance, one of my clients is a boutique consulting company. This past week some of the big players from there came out to the site to see how our work with this huge client was going.

I know what you're thinking -- surely everybody knows dozens of sing-a-long nuclear songs - but alas, it was tough sledding.

Fortunately, a team that included my mother-in-law won that year with a knock-off of "Yankee Doodle" that was called "Neutron Doodle"

What can I say? I like it! Hopefully you will too.

Here's more on the backstory. Enjoy.

In the same topic, GQ had a great rundown a few days ago about nuclear power. Why we aren't reprocessing spent fuel is beyond me.

Ludwig Wittgenstein
Couldn't there just once be a bikini model who was also a philosopher?
Seems like we always get guys like this.

Things are never what you think they are.

Take developing software. We call it that because -- duh! -- at the end of the day software is supposed to come out. When we work with teams, we always talk about our goals in terms of how the software is supposed to make the user's life easier.

But that's just a lie.

Then I slap myself around and sober up. Looks like the argument around global warming is still in the tank.

On one hand, people say its all emergent -- put a bunch of really smart people in a room with the Product Owner and fixed time-boxes and the conversation and code will follow along naturally. I don't think there is any denying that it's a true statement that software can emerge from shared conversations about problems.

On the other hand, there's the role of modeling in software development. Diagrams seem to help people understand and talk about things better, so couldn't they be part of a conversation as well?

I've been struggling with this, especially as a software and enterprise architect. Seems like people believe that modeling is part of the mindset of waterfall: that is, all the analysis happens, then all of the design, then all of the coding. In this worldview, modeling and modeling tools are just tools to control everything from the top down. It's a world where the "good" programmers control things for the "average" programmers. And when you model, you're not exactly doing one thing a time, are you? It's not like you're buying a story and going to make something of value happen for the Product Owner.

How to reconcile the good of modeling with the good of agile?

So in that spirit I'd like to Welcome Keith McMillan, fellow Agile Coach and technologist supreme. Keith has a blog over here. Those of you interested in the coaching and fast team game should check it out.

Here are some that caught my eye yesterday.

If you missed the lunar eclipse last week, here a hint: it was awesome!