28nd of the month

Received from Linked In at 12:10 am EST on May 29 (9:10pm May 28 in PT terms)

LinkedIn is currently unavailable while we make upgrades to improve our service to you. We’ll return around 9:30pm (PT) May 28nd, 2008.

We apologize for the inconvenience and appreciate your patience. Thank you for using LinkedIn!

The 28nd?

9:30 PT update: new message:

We’ll return around 9:45pm (PT) May 28th, 2008.

I like the noncommittal "Around" as a qualifier...

A semi-clean, well-lit, open-place

These are a few pictures of my team room. I love this place - high ceilings (with plenty of space for information radiators), lots of card walls, lots of white boards, movable filing cabinets, and a few cubes for the stationary folks. This is really a retail space the size of which you could probably house a basketball court.

We had an open space in the front that isn't pictured with a couch, some beanbag chairs, a conference table, a projection screen with a projector. We almost never had to schedule meetings in the limited conference space in the main building again.

A good view of most of the card wall. This is fairly old - we now have flipcharts with our historic burnup charts posted over the card wall so we can see our trends.

This gives a good view of the dimensions of our space.

The little white box area in the back is a portable office - 10x10, with privacy for personal phone calls, personnel meetings, etc.

The continuum

Is your software development approach agile or not?

Are you pregnant?

These are different questions. The latter question can be answered in a straightforward fashion... either you are or you aren't.

Using an agile methodology is a different question. Or an agile approach. Or an agile philosophy. Are you agile... yes or no?

The answer is almost always somewhere in between. You can use agile techniques (pairing, continuous integration, TDD, refactoring, user stories (following the INVEST principle), standups, abstract estimation techniques (e.g. points), iterations, velocity measurement, etc... in any degree. But what combination makes you "agile" ?

I think the answer is never yes or no, but the degree to which you espouse, promote, and enact agile approaches.

I think the continuum concept applies much more broadly than folks presume. Is your team "self-directed"? That's not a yes or no answer either.

Is being agile a good thing? Yes. Consider any course of human activity... being agile is better than being less agile. Am open to contrasting opinions, but I can't imagine an argument espousing being less able to adapt to change as being preferable. The chunked-up question is ... how useful are agile techniques in getting software delivered? I argue that the answer is "very". Why? The first answer lies in the fact that you NEED to be able to adapt to changes in your environment. Guess I'll save the remainder of the argument for a follow-up.

Top Chef Leadership

I'm becoming addicted to Bravo Network's "Top Chef" show. OK, so I'm generally addicted to cooking shows, but have, heretofore, confined my addiction to the Food Network.

I feel the role of a chef is a melding of cooking and leadership. Top Chef seems to focus more on the cooking aspect, and the extent to which folks step up in the delivery of good food. I think this misses a large part of the role of a chef. It's not enough to be able to deliver high quality food. You have to be adept at inspiring the other cooks in your kitchen to deliver.

Nikki, one of the chefs who was eliminated recently, was canned mostly because the menu was Italian, and she didn't exert leadership in driving the menu; her forte' is Italian food. So her inability to exert leadership was pivotal for her. One of the guys who escaped elimination focused on one dish - vs. another who went to the mat for the team in doing almost everything else.

When the elimination was announced, other chefs shook their heads. They knew that the one-dish guy should have been the one to go...

An ex-colleague of mine regales me of similar stories from her company. Promotions that make mouths gape, people surviving layoffs when more capable people are released. She sees some of the same aspects from "Top Chef" in that company. One-dish wonders survive because they play the game better than others. I sometimes wonder why "Top Chef" doesn't ask the other cooks directly about who should be eliminated.I guess that's show business.

The "Z" Word

Zealot: A fanatically committed person.

Hmmm... good or bad?

It suggests an unfavorable hue to me. I've seen this word used before to describe folks' commitment to a particular technology platform. He's a .NET zealot, or a Ruby zealot, or Zope zealot.

In the case of technology (most cases?) zealots prefer their approach/solution to all(?) others. For instance, how could you turn back from having written significant code in Ruby to doing plain old Java? Those who aren't writing in Ruby have simply not yet been shown "the way".

I consider myself fairly pragmatic and reasoned, but I seem to have acquired the dreaded tag at work. My zealotry is in an agile approach to software development. (English zealots - note the use of the article "an" vs. the article "the" - it's an important distinction).

I'm measuring whether I should shrug the label off, welcome it with open arms, or fight it. Actually ... that's not quite accurate. I'm pretty sure shrugging it off will not be my chosen response.

At some level, I feel it's like being called a "rationality" zealot... or a "damned common sense practitioner". I'm a "Sunrise Zealot" damn it ! I find the agile manifesto chock full of common sense. (OK, here I see... manifesto => zealotry... maybe if Kaczynski and Marx hadn't also used the term manifesto we'd be in better shape).

Some software development professionals unabashedly promote a "waterfall" approach using a document-centric "SDLC" lifecycle. Templates are created to capture every known aspect of the project. Stakeholders are forced to "sign off" on documents, which form a contract-like agreement to what will be delivered. Of course, a change request process is included, which affords the opportunity to create change documents which are then signed-off.

Agile is not binary... agile is a continuum. There are agile development techniques and agile project management approaches. You can use any of them - or not. The use of one technique does not an agile project make.

Agile, chunked up, (to me anyway) is about focusing on the delivery of quality software over and above delivering service to a process. The customer is not a color-copier and a list of signatories to a spec. The customer is the user of the software; the organization that benefits from working, functional, valuable software. No organization prefers reams of documents over working software. And those that argue voluminous documentation better leads to working, functional, valuable software should start measuring the extent to which those documents are implemented as stated. After all, not many approaches refine their processes to eliminate waste (ala Lean).

One should question the value of accepted process (using the Five Whys, for example) in order to assess the usefulness of documents and other artifacts to ensure they stand the test of reason.

OK, my writing therapy is done. I hereby embrace the label "Agile Zealot". I also accept the following additional labels: "Fatherhood Fanatic", "Beer Lover", and "Education Enthusiast".

I do like the alliteration angle though... may I please be an "Agile Aficionado" instead? Ah, but perhaps that doesn't quite capture the intensity of my rapture.